The current logic for switching between build types is not robust. If the script is run multiple times with different build types (e.g., first github, then gitlab), it can leave multiple build configurations active simultaneously (e.g., both *_github.tf and *_gitlab.tf would exist), which will cause Terraform to fail due to duplicate resource definitions. The script should ensure that only the target build type is active by deactivating all others.

A more robust approach would be to first deactivate any currently active build type configuration, and then activate the configuration for the selected target build type. This ensures a clean and predictable state regardless of how many times the script is run with different parameters.

# Deactivate all other build types to ensure a clean state
for type in "${build_types[@]}"; do
  if [[ "$type" != "$TARGET_BUILD" ]]; then
    find "$BASE_PATH" -name "*_$type.tf" -print0 | while IFS= read -r -d $'\0' file; do
      if [ -f "$file" ]; then
        new_name="${file}.example"
        echo "Deactivating: renaming \"$file\" to \"$new_name\""
        mv "$file" "$new_name"
      fi
    done
  fi
done

# Activate the target build type
find "$BASE_PATH" -name "*_$TARGET_BUILD.tf.example" -print0 | while IFS= read -r -d $'\0' file; do
  base_name="${file%.tf.example}"
  new_name="$base_name.tf"

  echo "Activating: renaming \"$file\" to \"$new_name\""
  mv "$file" "$new_name"
done

echo "File renaming complete."

The RenameBuildFiles function is called on c.FoundationPath, which points to the source directory of the foundation code. This modifies the source repository, which is a significant side effect. The helper tool should not alter the source code it's deploying from, as this can lead to an inconsistent state for the user and future deployments. The file renaming logic should be applied to the code after it has been copied to the target repository's checkout directory.

The output of the git clone command, which may contain the full repository URL with an embedded access token, is printed directly to stdout. If the command fails (e.g., repository not found), this will leak the secret token into the logs. The token should be redacted from any output before being printed or logged to prevent accidental exposure.

Can we bump to < 8? TPG v7 has been out for a while.

As practice we are recommend >= 1.3 given the frequent dependency on optional().

I recommend switching to a pessimistic operator rather than a static version. For example ~> 5.34, or more likely ~> 6.0 which has been out for a while.